CIS AWS Foundations Benchmarkの3.8に対応したCloudWatchアラームで特定のユーザのみ検知条件から外す
はじめに
CIS AWS Foundations Benchmarkの3.8(「S3バケットポリシー変更に対して、アラーム通知設定されていること」)に対応したCloudWatchアラーム・メトリクスフィルタ、及び関連リソースがある状態で、特定のIAMユーザのみ検知条件から外したくなったため、設定変更を行う方法を調べてみました。
前提
- CIS AWS Foundations Benchmarkの3.8の項目に対応したCloudWatchアラーム・メトリクスフィルタ、及び関連リソースが作成されている
やってみたこと
- 検証用のバケットを作成
- バケットポリシー変更イベント(PutBucketPolicy)を発生させる
- CloudWatchログに発生したイベントの確認
- メトリクスフィルタの編集
1.検証用のバケットを作成
マネジメントコンソールから katoaki-cis-test
というバケットを作成
2.バケットポリシー変更イベント(PutBucketPolicy)を発生させる
PutBucketPolicyを発生させるために、ダミーでマネジメントコンソールから katoaki-cis-test
バケットの[アクセス権限]-[バケットポリシー]とメニューを辿り、バケットポリシーエディタで以下のポリシーを入力
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicRead", "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::katoaki-cis-test/*" } ] }
3.CloudWatchログに発生したイベントの確認
- CloudTrailに設定されているロググループ(私の場合は
CloudTrail/DefaultLogGroup
というロググループ名でした)を開き、PutBucket
でフィルタし、手順2で実施したイベントの発生を確認
- 【任意】次の手順で、フィルタパターンを検証するのに使うため、マネジメントコンソール上からタイムスタンプとメッセージの出力をコピーして控えておきます
4. メトリクスフィルターの編集
- 手順3で確認したロググループのメトリクスフィルターの領域を表示し、CIS3.8用に作成したメトリクスフィルターを見つけて開きます。(検索で
Bucket
などと入力すると見つけやすいと思います)
- 特定のIAMユーザを除外するために、フィルタパターンに
($.userIdentity.userName!=<IAMユーザ名>)
をAND条件で追加します。例えば、下記のような設定値になります。
{ ($.userIdentity.userName!=<IAMユーザ名>) && ($.eventSource = s3.amazonaws.com) && (($.eventName =PutBucketAcl) || ($.eventName = PutBucketPolicy) || ($.eventName = PutBucketCors) ||($.eventName = PutBucketLifecycle) || ($.eventName = PutBucketReplication) ||($.eventName = DeleteBucketPolicy) || ($.eventName = DeleteBucketCors) || ($.eventName= DeleteBucketLifecycle) || ($.eventName = DeleteBucketReplication)) }
- 【任意】「パターンをテスト」セクションで、カスタムログデータに手順3で控えておいたログメッセージがあれば、それを貼り付けてテストします。フィルタパターンを修正前のものと切り替えてみると、指定したIAMユーザ名の場合には検出されないことが確認できます
5. 動作確認
PutBucketPolicyを発生させるために、バケットポリシーエディタでポリシーを変更してみます。 Resource
の値をダミーの値に変更します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "PublicRead", "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::katoaki-cis-test/test*" } ] }
変更後に CloudTrail/DefaultLogGroup
のロググループ名でした)を開き、 PutBucket
でフィルタし、直前の手順で実施したイベントの発生を確認した上で、アラームの状態は「OK」のままになっていることを確認します。